Determining a distributed system topology from a single application deployment

ABSTRACT

Systems and methods for determining a topology of an application deployment on a distributed system can include receiving multiple traces of requests within an application, where the application includes multiple components. They can also include determining a number of times that each span between the components is traversed by a trace and associating each span with a corresponding weight reflecting the number of times that the span is traversed. Such systems and methods can further include selecting a deployment scenario based on the respective weights of each of the spans.

TECHNICAL FIELD

The disclosure is generally related to computer systems, and moreparticularly, to determining system topology of microservice-basedapplication deployments.

BACKGROUND

Microservices are autonomous executable code services that can worktogether to form an application. They can be pieces of softwareinstruction code, which compute responses for client requests. Forexample, if a client sends a request a microservice can respond to thatrequest. Microservices may be deployed in a distributed system or“microservice system” in a clustering platform. Microservices can permitan application to be structured as a collection of loosely coupledcomponents. Thus, the utilization of microservices can break downcomplex applications into small independent processes to producehighly-decoupled systems. The microservices may be executed incontainers to create containerized applications. Containerization is anoperating-system (OS)-level virtualization environment of a host machinethat provides a way to isolate the microservice process. Accordingly,each microservice can be focused on doing a relatively simple task tosupport the application within each individual container. One primarybenefit of microservices is that some types of applications can be moreeasily built and maintained by being broken down into smaller composableinteroperable pieces. Each component can then be continuously developedand separately maintained to improve the application without having todisturb the entire application. This is in contrast to a traditional,monolithic application which is all developed, updated, and maintainedall in one piece.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure is illustrated by way of examples, and not by way oflimitation, and may be more fully understood with references to thefollowing detailed description when considered in connection with thefigures, in which:

FIG. 1 depicts a block diagram of an example network architecture, inaccordance with one or more implementations of the disclosure.

FIG. 2 depicts a flow diagram of an example method for determining asystem topology for an application deployment, in accordance with someimplementations.

FIG. 3 depicts a flow diagram of an example method for determining asystem topology for an application deployment, in accordance with someimplementations.

FIG. 4A illustrates a block diagram of an example application, inaccordance with some implementations.

FIG. 4B illustrates a block diagram of an example application, inaccordance with some implementations.

FIG. 5 depicts a block diagram of an example computer system inaccordance with one or more implementations of the present disclosure.

FIG. 6 depicts a block diagram of an illustrative computing deviceoperating in accordance with the implementations of the disclosure.

DETAILED DESCRIPTION

Described herein are methods and systems for determining a distributedsystem topology of a microservice application system deployment. Amicroservice system topology can be a representation of communicationpaths between components of a microservice based application. Amicroservice-based application is a collection of microservices, whichcan be processes (e.g., instantiated from respective software modules)that evaluate and provide responses for client requests. For example,responsive to receiving a request from a client, a microservice canperform an evaluation (e.g., an operation) related to the request andsend a response to that request from the client. The client itself canalso be a microservice. Microservices may be deployed in a microservicesystem using a microservice clustering platform.

Microservices can interact and work together in a variety of ways withina microservice-based application. For example, if a user of an employeeonboarding application wants to access an employer's system, they mayneed to verify their identity. Accordingly, the microservice thatcommunicates with the employer company's employee database may need tocommunicate with a fraud prevention microservice, which itself may needto communicate with a user identity verification microservice. Toprovide better efficiency, this employer company might eventually builda microservice that gives users different options for identityverification. This new microservice may also need to communicate withone or more of the existing microservices. Modern applications may bebroken down in this way, as a network of microservices each performing aspecific function and capable of being independently developed anddeployed.

Use of microservices allows for creation of highly-decoupled systems bybreaking down complex applications into relatively simple independentlydeployable processes. A containerized computing services platform, suchas a platform-as-a-service (PaaS) or a function-as-a-service (FaaS)system, may implement microservices. The microservices can be executedin containers to create containerized applications in a containerizedcomputing services platform. Containerization is an operating-system(OS)-level virtualization environment of a host machine that provides away to isolate the microservice process. Each microservice process canbe focused on doing a relatively simple operation to enable thefunctionality of the application within each individual container.

Such applications can be developed in a containerized softwaredevelopment environment by multiple entities (e.g., differentdevelopers). A container may be an execution environment represented byan isolated virtualized user-space instance of an operating system, suchthat the user-space instance is associated with a kernel instance whichmay be shared with other containers. The containers may be employed tostore the software application code and microservices (e.g., a utilityprogram such as a compiler) for performing operations on the softwarecode. A microservice may be an independently-deployable modular servicethat may communicate with other services in a system (e.g., acloud-based system) through a lightweight interface. The code of thesoftware application may be stored along with microservices incontainers to create containerized applications. The containerizedapplication may be released as a software product that can be executedby the PaaS or FaaS system as a self-contained application on computingnodes in a cloud (i.e., a distributed computing system having resourceslocated at different locations). Each of the computing nodes (e.g., ahost computer, a virtual machine, etc.) may support a containerexecution environment.

In some embodiments, an application may be deployed as a plurality ofservices (e.g., microservices) on one or more of the computing nodes.Each of the services may be hosted by one or more containers. Moreparticularly, for example, multiple replicas of a service may be host bya plurality of containers running on one or more nodes. Each of thereplicas may represent an instance of the service and may provide thesame functionality of the service. In many situations it is beneficialto host and deploy each container and/or microservice independently ofeach other. This may entail deploying and hosting the microservice ondifferent and separate sets of computing resources or in differentphysical/geographic locations. Being able to deploy microservices indisparate locations and on different resources can provide moreefficient execution of the processes of each microservice independentlyand allow different microservices to be developed in differentdevelopment environments while still remaining interoperable within alarger application. This leads to the need of determining a topology forthe deployment of the microservices within a distributed computingsystem.

Some approaches to deploying and hosting applications and/or servicesmay use various heuristics in order to determine how to break up anapplication topology into independently and jointly deployablecomponents (e.g., microservices). For example, some approaches are basedon reasoning about the business domain or intuiting the code componentswhich should belong together without consideration of practicalindicators of system efficiency. Applications divided and distributedaccording to these methods may result in inefficient microservicegroupings being deployed together and microservices in frequentcommunication with one another being deployed independently. This,consequently, may lead to increased downtime and increased communicationcosts for running and maintaining the application of which themicroservices are constituent components.

Aspects of the disclosure address the above-described and otherdeficiencies by providing systems and methods for determining anapplication system topology for constituent component (e.g.,microservice) deployment. In accordance with one or more implementationsof the present disclosure, an analysis of traces of requests acrossvarious components of an application can be used to determine howstrongly coupled a particular pair of components is within theapplication. A trace can be a record of a path that a request followsthrough an application system. A trace is composed of one or more spans,where each span is a named timed operation together with the requestthat initiates the operation and the response generated after theoperation which represent a part of the workflow of the application.Accordingly, tracing is technique used to analyze microservices withinan application and to see which microservices communicate with eachother (e.g., get called by other microservices) and under whatparameters this occurs (e.g., determine which requests that got invokedunder each service). The number of times the traces traverse each spanbetween the constituent components of the application can be associatedwith a weight attributable to each respective span. In someimplementations, the weights of each span can serve as a basis forselecting a deployment scenario having a particular applicationcomponent topology. Consequently, the application components can bedeployed according to the deployment scenario such that the componentsthat are in frequent communication are merged and deployed jointly whilecomponents that communicate more infrequently are deployedindependently.

In some implementations, the components of an application can beinitially defined either as executable elements (e.g., microservices)within a monolithic application code or as interconnected composableexecutable elements within an application with distinct separatecomponents, some of which may already be either jointly or separatelydeployed. In this context, composable systems and components are thosethat can be selected and assembled in various combinations to satisfyspecific user requirements while maintaining the essential features ofbeing self-contained (i.e., modular and able to be deployedindependently and able to cooperate with other components) and stateless(i.e., treating each request as an independent transaction unrelated toany previous request). Traces can be requested and performed to trackthe path that requests take between the components of the application.

The performance of a trace, also referred to as tracing herein, caninclude collecting data as a request makes its way through anapplication. In one implementation, to make each trace identifiableacross all the different components of an application, a unique ID canbe assigned to each request and a unique ID can be assigned to each stepin a trace, encoding contextual information. Further, the encodedcontext can be passed (i.e., propagated) from one service to the next asthe request makes its way through the application environment. Thisallows the correlation of each step of a trace across the spans betweenapplication components, in the correct order, along with other necessaryinformation to track the requests. The traces can be performed over aparticular period of time during which the application is subject totypical use. In one implementation, traces of all possible requestswithin the application can be performed.

Thus, once the traces are performed, every span traversed by one or moreof the traces can be given (i.e., assigned or associated with) a weight.The weight of a span can reflect the number of times the span istraversed by a trace. In some implementations, there may be a thresholdcriterion (e.g., a threshold value, a minimum weight that ispre-determined by a user or an application setting) with which theweights of each of the spans can be compared by a device in adistributed computing system as described in more detail below withreference to FIG. 1 . The components between which the spans haveweights that satisfy the threshold criterion (e.g., have weights thatare greater than the threshold value) can, within a deployment scenario,be deployed jointly, while components between which the spans haveweights that do not satisfy the threshold criterion (e.g., have weightsthat are less than the threshold value) can be deployed independentlywithin the deployment scenario. As used herein, components beingdeployed jointly or together means that the components are hosted andexecuted on the same set of computing resources (e.g., a server, avirtual machine, a container, etc.) that may be located at one physicallocation (e.g., within the same data center, physical machine, etc.)

A deployment scenario can be chosen such that some or all of theapplication components having spans between them with weights thatsatisfy the threshold criterion are deployed together (i.e., at the samelocation or on the set of computing resources, such as on the samemachine, computing node, container, etc.) while some or all of thecomponents having spans between them with weights that do not satisfythe threshold criterion are deployed separately (i.e., at differentlocations or on different sets of computing resources, such as on thedifferent machines, computing nodes, containers, etc.). Then, theapplication components can be deployed according to the selecteddeployment scenario.

In some implementations, a directed weighted graph can be constructedfrom the traces where each node of the graph would represent a startingor ending point of a span traversed by a trace. In one implementation,the weight assigned an edge between two nodes of the graph can becalculated as the proportion of the total number of traces thattraversed the particular span between the two nodes (i.e., the sum ofall the traces that traverse the span between the two nodes divided bythe number of all traces performed). Accordingly, in thisimplementation, the maximum weight that can be given to a particularspan will be a weight of 1 which will occur when all the traces of theapplication traverse the span. Analogously, in this implementation, theminimum weight that can be given to a particular span will be a weightof 0 which will occur when none of the traces of the applicationtraverse the span.

In some implementations, the directed weighted graph can be traversedwith a Depth First Search (DFS) to determine the number of times eachspan is traversed and, therefore, the proportion of traces that traverseeach span. In DFS, each path that a trace takes is traversed startingfrom the root node (i.e., the component where the trace requestoriginates) to the end node of each path of the possibility tree (i.e.,a tree diagram of all the possible paths a request could take within theapplication). Thus, in some implementations, as a result of theperformance of the traces, each edge connecting two nodes (e.g.,representing application components) of the graph can be assigned acorresponding weight reflecting the weight of the corresponding span.These resulting weights, for each edge, can be compared against athreshold criterion. The threshold criterion can reflect a “mergefactor” that determines whether components should or should not bemerged. In some cases the components can be merged into a singledeployment but separate from other components deployed as part of theapplication.

For example, the threshold criterion can be whether or not a valueassociated with a span exceeds a threshold value. For example, athreshold number value can be set such that components having spansbetween them with weights larger than the threshold value (i.e.,predetermined merge factor) are identified for merging (e.g., fordeploying together) while components having spans between them withweights smaller than the threshold value are recommended to be deployedseparately. The recommendations can take the form of deploymentscenarios of suggested application component deployment groupingsindicating which components should be deployed together (i.e., jointlyin one location or on one set of computing resources) and whichcomponents should be deployed separately (i.e., independently atdifferent location or on different sets of computing resources).

A deployment scenario can be a visual representation of a directed graphof application components showing one or more of the components beingmerged or positioned close together within the representation (i.e., toindicate that these components should be deployed together) and havingone or more components being split off or distanced away from one ormore of the other components (i.e., to indicate that these componentsshould be deployed separately). As explained in more detail withreference to FIG. 1 such visualizations can be generated by a computingdevice of a distributed computing system and shown to a user. For eachapplication and corresponding weighted directed graph one or more suchscenarios can be generated and selected either automatically or by auser. In some implementations, once the recommended componentdeployments are produced as scenarios, manual adjustment may beperformed if changes are necessary based on additional factors andoperational specifics of each of the components. For example, adjustmentmay be beneficial in a situation where two microservices that have avery different functions, despite one service being invoked very oftenby the other and therefore having a span between them assigned a highweight.

Thus, the selected scenarios may include indication of which of thevarious components of an application should be jointly or separatelydeployed. Similarly, the scenarios can include indications of whetherpreviously separately deployed components should be merged and deployedtogether and whether previously merged or jointly deployed componentsshould be separated and deployed apart from each other. In someimplementations, the guiding principle may be that the higher theproportion of traces that traverse a span between any two givencomponents, the higher the likelihood that the operation of theapplication would be more efficient if the components were deployedtogether. Conversely, according to the same principle. The lower theproportion of traces that traverse a span between any two givencomponents, the higher the likelihood that the operation of theapplication would be more efficient if the components were deployedseparately.

Accordingly, the constituent components of the application can then betaken and deployed or redeployed according to the recommendationincluded in the desired scenario. As noted earlier, deployment of anapplication component may include the hosting of a component at aparticular physical location and executing/running the component on aparticular set of computing resources either together with or separatelyfrom other components of the same application. These and other featuresof the implementations can be better understood with reference to FIGS.1-6 described below. To provide context for the various implementationsand the determination of a distributed system topology for applicationcomponent deployment, an example network architecture is initiallydescribed below.

FIG. 1 is a block diagram of a network architecture 100 in whichimplementations of the disclosure may operate. In some implementations,the network architecture 100 may be used in a containerized computingservices platform. A containerized computing services platform caninclude a Platform-as-a-Service (PaaS) system or a Function-as-a-Service(FaaS) system. PaaS and FaaS systems can provide resources and services(e.g., microservices) for the development and execution of applicationsowned or managed by multiple users. Such systems can provide a platformand environment that allow users to build applications and services in aclustered computing environment (the “cloud”). Although implementationsof the disclosure are described in accordance with a certain type ofsystem, this should not be considered as limiting the scope orusefulness of the features of the disclosure. For example, the featuresand techniques described herein can be used with other types ofmulti-tenant systems and/or containerized computing services platforms.

As shown in FIG. 1 , the distributed computing system 100 may include acloud-computing environment 130 (also referred to herein as a cloud)that includes computing nodes 111, 112, 121, 122 to execute applicationsand/or processes (e.g., services, microservices, etc.) associated withthe applications. A “computing node” providing computing functionalitymay provide the execution environment for an application of the PaaS orFaaS system. In some implementations, the “computing node” may refer toa container or virtual machine (VM) that is hosted on a physicalmachine, such as host 1 110 through host N 120, implemented as part ofthe cloud 130. In some implementations, the host machines 110, 120 canbe located in a data center. For example, both computing nodes 111 and112 can be hosted on the same physical machine 110 in cloud 130 providedby cloud provider 104. In other implementations, different processes ofthe same application can be deployed to computing node N 112 andcomputing node 1 121 with each node being hosted by different physicalmachines 110 and 120 and respectively located in disparate geographiclocations and within different local networks. In some implementations,an environment other than a container or VM may be used to executefunctionality of the PaaS or FaaS system applications. When computingnodes 111, 112, 121, 122 are implemented as containers or VMs, they mayeach be executed by respective operating systems (OSs) 115, 125 on eachrespective host machine 110, 120.

In some implementations, the host machines 110, 120 may be located inthe same data center while in other implementations, the host machines110, 120 can be located in different data centers in remote physicallocations from each other. Users can interact with applications or theirconstituent services and microservices executing on the cloud-basedcomputing nodes 111, 112, 121, 122 using client computer systems, suchas clients 160, 170 and 180, via corresponding user interfaces (e.g.,web browser applications) 161, 171 and 181. In other implementations,the applications or their constituent components may be hosted directlyon hosts 1 through N 110, 120 without the use of VMs (e.g., a “baremetal” implementation), and in such an implementation, the hoststhemselves are referred to as “computing nodes”.

Clients 160, 170, and 180 can be connected to hosts 110, 120 in cloud130 and the cloud provider system 104 via a network 102, which may be aprivate network (e.g., a local area network (LAN), a wide area network(WAN), intranet, or other similar private networks) or a public network(e.g., the Internet). Each client 160, 170, 180 may be a mobile device,a PDA, a laptop, a desktop computer, a tablet computing device, a serverdevice, or any other computing device. Each host 110, 120 may be aserver computer system, a desktop computer or any other computingdevice. The cloud provider system 104 may include one or more machinessuch as server computers, desktop computers, etc.

In one implementation, the cloud provider system 104 is coupled to acloud controller 108 via the network 102. The cloud controller 108 mayreside on one or more machines (e.g., server computers, desktopcomputers, etc.) and may manage the execution of applications in thecloud 130. In some implementations, cloud controller 108 receivescommands from the containerized system controller 140. In response tothese commands, the cloud controller 108 can provide data associatedwith different applications to the cloud provider system 104. This datamay be used for the execution of application components in acontainerized computing services platform managed by the containerizedsystem controller 140.

In one implementation, the data is used for execution of containers 191,192, 193, 194 in one or more pods 151, 152, 153. The pods 151, 152, 153can be a group of one or more containers that are deployed together onthe same node 111, 112, 121, and can be the smallest compute unit thatcan be defined, deployed, and managed in the containerized computingservice environment. For example, each microservice of the applicationmay be executed in one of the containers 191, 192, 193, 194. Each pod151, 152, 153 can be allocated its own internal IP address, withcontainers 191, 192, 193, 194 in pods 151, 152, 153 being able to sharelocal storage and networking. Pods 151, 152, 153 can have a lifecyclethat is pre-defined and can run on a node 111, 112, 121 until the pod'scontainers exit or they are removed for some other reason.

The containers 191, 192, 193, 194 can include application componentimages built from pre-existing application components and source code ofusers managing the application. An image may refer to data representingexecutables and files of the application component used to deployfunctionality for a runtime instance of the application. A container191, 192, 193, 194 can be a secure process space on the nodes 111, 112,121 to execute functionality of an application or an applicationcomponent. In some implementations, a container 191, 192, 193, 194 canbe established at the nodes 111, 112, 121 and 122 with access to certainresources of the underlying node, including memory and storage.

In some implementations, the containerized system controller 140 mayimplement a microservice deployment component 142. The microservicedeployment component 142 may provide visualizations of a distributedmicroservice deployment network topology implemented by containerizedsystem controller 140 via nodes 111, 112, 121. For example, computingnodes 111, 112, 121 may be utilized to implement a microservicedeployment network topology that deploys microservices via pods 151,152, 153. Pods 151, 152, 153 can provide the workload of themicroservices of the microservice network, as discussed herein. Themicroservice deployment component 142 may provide the visualizations ofthe microservice network topology to one or more requesting users atclient devices 160, 170, 180. For example, in response to a request fora particular microservice network topology graph type, microservicedeployment component 142 may transmit generated visualization data forthe requested microservice network graph type to client device 160, 170,180 to be rendered via a GUI for display to the requesting user using,for example, browser 161, 171, 181 at client device 160, 170, 180.

As discussed above, a microservice network can include components suchas workloads, application, services, and microservices. The componentsof the microservice network can be represented in a graph of directeddiagram nodes with diagram nodes in the graph representing themicroservices of the microservice network. Such a graph may be referredto herein as a microservice network graph or a “graph”. A microservicenetwork graph may represent each workload, application, service, ormicroservice as a node in the microservice network graph. Diagram nodesin the microservice network graph may be connected to one another basedon which components of the microservice network are communicating withone another. For example, if component A sends a request to component B,the microservice network graph depicts the two diagram nodes A and Bconnected via an edge.

In some implementations, microservice deployment component 142 canreceive traces of requests originating at a component of an applicationdeployed on one or more devices of the distributed computing system 100.A trace of a request can be the path of a request generated by acomponent of an application as it traverses the network of applicationcomponents. Microservice deployment component 142 may also perform thetraces and track the path of the requests within the microservicenetwork. In some implementations, the microservice deployment component142 can perform the traces at regularly scheduled time intervals or forsome fraction of the requests that are generated by a component of theapplication in the microservices network. The traces can be performedover a pre-determined period of time or continuously during theoperation of the application. For example, the microservice deploymentcomponent 142 can trace every request generated by every root componentof an application through each component of the application that ittraverses. In one implementation, the microservice deployment component142 can assign a unique ID to each request and a unique ID to each stepin a trace to encode contextual information. Further, the microservicedeployment component 142 can propagate the encoded context along withthe request from one service to the next as the request makes its waythrough the application environment. Thus, the microservice deploymentcomponent 142 can collect the data from all of the traces for furtherprocessing and analysis. Having performed the traces, the microservicedeployment component 142 can determine the number of times each spanbetween application components is traversed by a trace and associateeach span with a corresponding weight value. In some implementations,the microservice deployment component 142 can assign a weight to a spanthat is indicative of the number of times the span is traversed by atrace. In other implementations, the microservice deployment component142 can assign a weight to a span that is reflective of a proportion oftraces that traverse the span out of the total number of tracesperformed.

Microservice deployment component 142 may provide various visualizationsof the microservice network topology based on the metadata of themicroservices (i.e., data descriptive of the interconnections of themicroservices along with their related requests and responses torequests) of the microservice network. The metadata may be stored in adata store maintained by containerized system controller 140 ormaintained separately from containerized system controller 140.

Microservice deployment component 142 may utilize microservice metadatato generate several different microservice network graph types depictingvarious microservice network topologies that represent the microservicenetwork implemented by containerized system controller 140.

In one implementation, microservice deployment component 142 may receivea user request for a particular type of microservice network graph typefor a microservice network topology. Based on the requested microservicenetwork graph type, microservice deployment component 142 may access themicroservice data store to identify the microservice network diagramnodes and the connections between such diagram nodes in order togenerate the requested microservice network graph type for themicroservice network topology.

In some implementations, microservice deployment component 142 cangenerate a microservice deployment topology that reflects howmicroservices can be deployed in a distributed computing system 100. Thedeployment topology may be a visual graphical representation of asub-set of the application's microservices being deployed jointly (e.g.,on the same set of computing resources) and of a sub-set of theapplication's microservices being deployed separately (i.e., ondifferent sets of computing resources). The microservice deploymentcomponent 142 can generate (e.g., by visual representation on a userinterface 161, 171, 181) one or more deployment scenarios where adifferent microservice deployment topology is included in each scenario.The microservice deployment component 142 can recommend the scenarios toa user. Each of the scenarios can depict or reflect various combinationsof application components (e.g., microservices) being merged or splitfrom each other for deployment. In some implementations, mergedmicroservices in a scenario can indicate that the merged microservicesshould be deployed together on the same set of computing resources whilesplit microservices in the scenario may indicate that the separatemicroservices can be deployed independently on different sets ofcomputing resources.

The microservice deployment component 142 can, therefore, select amicroservice deployment scenario and a corresponding microservicenetwork topology based on the respective weights of each of the spansbetween the components of the application. This selection can includedetermining whether the weight of a given span satisfies a thresholdcriterion. The threshold criterion may be a threshold weight value.Accordingly, a weight satisfying the criterion can be a weight thatexceeds a threshold weight value while a weight failing to satisfy thethreshold criterion can be weight that is less than a threshold weightvalue. In some implementations, components having a span assigned aweight value that is higher than a threshold value can be merged andcomponents having a span assigned a weight value that is lower than thethreshold value can be split.

Therefore, when generating scenarios, the microservice deploymentcomponent 142 can merge components together for them to be deployedjointly and can split components for them to be deployed separatelybased on the weight values of the spans between the components.Similarly, when selecting scenarios, the microservice deploymentcomponent 142 can select scenarios where components are either merged orsplit based on the weight values of the spans between them.Consequently, the microservice deployment component 142 can then deploythe components (e.g., microservices) of the application in therespective containers 191, 192, 193, 194, of the respective pods 151,152, 153, computing nodes 111, 112, 121, and hosts 110, 120 of thedistributed computing system 100 according to the selected deploymentscenario.

In some embodiments, the microservice deployment component 142 caninclude one or more components described in connection with FIG. 6 andcan implement one or more methods described in connection with FIGS. 2-3. While various implementations are described in terms of theenvironment described above, the functionality may be implemented in avariety of other environments including a single, monolithic computersystem, as well as various other combinations of computer systems orsimilar devices connected in various ways. For example, the microservicedeployment component 142 may be running on a computing node, such ascomputing nodes 111, 112, 121, 122, of the system 100 hosted by cloud130, or may execute external to cloud 130 on a separate server device.In some implementations, the microservice deployment component 142 mayinclude more components than what is shown that operate in conjunctionwith the PaaS or FaaS system of network 100.

The procedure for determining a microservice application deploymenttopology is described with reference to FIG. 2 . FIG. 2 depicts a flowdiagram of an example method 200 for determining a system topology foran application deployment, in accordance with some implementations. Insome implementations, at block 202, the processing logic can receive oneor more traces of requests within an application having one or morecomponents (e.g., microservices). The traces can begin at a componentthat originated a request and track a path through the components of theapplication across one or more spans between the components. Forexample, the processing logic can trace every request generated by everyroot component of an application through each component of theapplication that it traverses. In one implementation, the processinglogic can assign a unique ID to each request and to each step in a traceto encode contextual information. Further, the processing logic canpropagate the encoded context along with the request from one service tothe next as the request makes its way through the applicationenvironment. Thus, the processing logic can collect the data from all ofthe traces for further processing and analysis.

After the traces of the requests are performed and received at block202, the processing logic can, at block 204, determine the number oftimes that each span between the components of the application istraversed by a trace. In some implementations, a span between any twogiven components of an application can be traversed by one or moretraces as the traces of requests are performed in the application. Thus,the processing logic can count the number of times that each spanbetween application components is traversed by a trace.

Accordingly, at block 206, the processing logic can associate each spanwith a corresponding weight reflecting the number of times that the spanis traversed. In some implementations, the processing logic can assign aweight to a span such that the weight indicates the raw number of timesthat the span was traversed. In other implementations, the processinglogic can assign a weight to a span that represents a proportion of thetotal traces that were performed in the application that happened totraverse the span.

Consequently, the processing logic can, at block 208, select adeployment scenario based on the respective weights of each of thespans. Each deployment scenario can include different applicationcomponent deployment combinations where the components are either mergedor split based on the weights given to the spans between them. Thedeployment scenario may be a visual graphical representation of atopology of the distributed components of an application showing asub-set of the application's microservices being deployed jointly (e.g.,on the same set of computing resources) and of a sub-set of theapplication's microservices being deployed separately (i.e., ondifferent sets of computing resources). In some implementations, atblock 210, the processing logic can deploy the components of theapplication according to the deployment scenario. This can includedeploying components that are merged in the scenario on the same set ofcomputing resources while deploying components that are split onseparate sets of computing resources. Another implementation can includeadditional operations being performed by the processing logic. One suchexample implementation is described below with reference to FIG. 3 .

FIG. 3 depicts a flow diagram of an example method 300 for determining asystem topology for an application deployment, in accordance with someimplementations. In these implementations, the processing logic can, atblock 302, receive traces of requests originating at a component of anapplication deployed on one or more devices of the distributed computingsystem 100. A trace of a request can be the path of a request generatedby a component of an application as it traverses the network ofapplication components. The processing logic may, at block 303, alsoperform the traces and track the path of the requests within themicroservice network. In some implementations, the processing logic can,at block 303, perform the traces at regularly scheduled time intervalsfor all requests or for some fraction of the requests that are generatedby a component of the application in the microservices network. Thetraces can be performed over a pre-determined period of time orcontinuously during the operation of the application.

Having performed the traces, the processing logic can, at block 304,determine the number of times each span between application componentsis traversed by a trace. The processing logic can, at block 304, countthe number of times a span is traversed by a trace and, at block 306,associate the span with a weight value. Associating a weight value witha span can include assigning the weight value for the span in themetadata of the application components serving as the endpoints of thespan. In some implementations, the processing logic can, at block 306,assign a weight to a span that is indicative of the number of times thespan is traversed by a trace or reflective of a proportion of tracesthat traverse the span out of the total number of traces performed inthe application.

The processing logic can generate visualization of the microservicenetwork topology based on the metadata of the microservices (i.e., datadescriptive of the interconnections of the microservices along withtheir related requests and responses to requests) of the microservicenetwork. The processing logic may utilize microservice metadata togenerate several different microservice network graph types depictingvarious microservice network topologies that represent the microservicenetwork implemented by containerized system controller 140.

In one implementation, the processing logic may, at block 308, receive auser request for a particular type of microservice network graph typefor a microservice network topology. Based on the requested microservicenetwork graph type, the processing logic may access the microservicedata store to identify the microservice network diagram nodes and theconnections between such diagram nodes in order to generate therequested microservice network graph type for the microservice networktopology.

In some implementations, the processing logic can generate amicroservice deployment topology that reflects how microservices can bedeployed in a distributed computing system 100. The deployment topologymay be a visual graphical representation of a sub-set of theapplication's microservices being deployed jointly (e.g., on the sameset of computing resources) and of a sub-set of the application'smicroservices being deployed separately (i.e., on different sets ofcomputing resources). The processing logic can, at block 308, generate(e.g., by visual representation on a user interface 161, 171, 181) oneor more deployment scenarios where a different microservice deploymenttopology is included in each scenario. The processing logic can, atblock 208, recommend the scenarios to a user. Each of the scenarios candepict or reflect various combinations of application components (e.g.,microservices) being merged or split from each other for deploymentbased on the weight of the spans between them. In some implementations,merged microservices in a scenario can indicate that the mergedmicroservices should be deployed together on the same set of computingresources while split microservices in the scenario may indicate thatthe separate microservices can be deployed independently on differentsets of computing resources.

The processing logic can, therefore, at block 208, select a microservicedeployment scenario and a corresponding microservice network topologybased on the respective weights of each of the spans between thecomponents of the application. This selection can include determining,at block 381, whether the weight of a given span satisfies a thresholdcriterion. The threshold criterion may be a threshold weight value.Accordingly, a weight satisfying the criterion can be a weight thatexceeds a threshold weight value while a weight failing to satisfy thethreshold criterion can be weight that is less than a threshold weightvalue. Conversely, a weight satisfying the criterion can be a weightthat is less than a threshold weight value while a weight failing tosatisfy the threshold criterion can be weight that exceeds a thresholdweight value. In some implementations, the processing logic can, atblock 382, merge components having a span assigned a weight value thatis higher than a threshold value and, at block 384, split componentshaving a span assigned a weight value that is lower than the thresholdvalue.

Therefore, when generating scenarios, at block 308, the processing logiccan merge components together, at block 382, for them to be deployedjointly, and can split components, at block 384, for them to be deployedseparately based on the weight values of the spans between thecomponents. Similarly, when selecting scenarios, the processing logic,can, at block 308, select scenarios where components are either mergedor split, at block 382 and 384 respectively, based on the weight valuesof the spans between them. Consequently, the processing logic can, atblock 310, then deploy the components (e.g., microservices) of theapplication in the respective containers 191, 192, 193, 194, of therespective pods 151, 152, 153, computing nodes 111, 112, 121, and hosts110, 120 of the distributed computing system 100 according to theselected deployment scenario.

Examples of application component network graphs showing multiple tracescan be understood with reference to FIGS. 4A-4B. For example, FIG. 4Aillustrates a block diagram of an example application 420, in accordancewith some implementations. In one implementation, an application 420 caninclude multiple components, specifically, component A 422, component B424, component C 426, and component D 428. The illustrated graph alsoshows traces of requests that have occurred within the application 420.

Thus, out of a total number of 6 traces, 5 traces traversed the span 421between component A 422 and component B 426. In this exampleapplication, 3 traces traversed the span 423 between component B 424 andcomponent D 428, and one trace traversed each span 427, 425 respectivelybetween component A 422 and component C 426, and between component C 426and component D 428. Accordingly, the span 421 can be associated with aweight value of 0.83 and the span 423 can be associated with a weight of0.5. Analogously, the span 427 and the span 425 can each be associatedwith a weight of 0.17. In this example the weights are reflective of aproportion of the total number of traces performed that traversed thegiven span.

In one implementation, if the merge factor (i.e., the thresholdcriterion value) is 0.75, then a scenario that merges some of thecomponents and splits some of them can be selected. For example,component A 422 and component B 424 can be merged in the selecteddeployment scenario because the span 421 has a weight of 0.83 which ishigher than the merge factor 0.75. However, component C 426 andcomponent D 428 can be deployed separately because none of the spans ofwhich they are an endpoint have a weight value higher than 0.75.However, if the merge factor was 0.4, then any combination of componentA 422, component B 424, and component D 428 could be merged to bedeployed together and component C could be split off to be deployedseparately.

A different set of traces can occur in a different application. Forexample, FIG. 4B illustrates a block diagram of an example application440, in accordance with some implementations. In one implementation, anapplication 440 can include multiple components, specifically, componentA 442, component B 444, component C 446, and component D 448. Theillustrated example also shows traces of requests that have occurredwithin the application 440.

Thus, out of a total number of 6 traces, 4 traces traversed the span 441between component A 442 and component B 446. In this exampleapplication, 3 traces traversed the span 443 between component B 444 andcomponent D 448, and two traces traversed each span 447, 445respectively between component A 442 and component C 446, and betweencomponent C 446 and component D 448. Accordingly, the span 441 can beassociated with a weight value of 0.67 and the span 443 can beassociated with a weight of 0.5. Analogously, the span 447 and the span445 can each be associated with a weight of 0.33. In this example graphthe weights are also reflective of a proportion of the total number oftraces performed that traversed the given span.

In one implementation, if the merge factor (i.e., the thresholdcriterion value) is 0.75 as in the previous example, then a scenariothat splits all of the components can be selected. Because all of thespans have weight values that are below the threshold merge factor 0.75,all of them can be deployed independently. However, if the merge factoris 0.5, component A 442 and component B 444 can be merged in theselected deployment scenario as can component B 444 and Component D 448because the span 441 and the span 443 have a weight which is higher thanthe merge factor 0.5. Accordingly, component C 446 and component D 448can be deployed separately because none of the spans, 447, 445, of whichthey are an endpoint have a weight value higher than 0.5. In thismanner, scenarios can be generated and selected such that theconstituent components (e.g., microservices) of an application areeither merged or split based on the weights assigned to the spansbetween them.

FIG. 5 depicts a block diagram of a computer system 500 operating inaccordance with one or more aspects of the present disclosure. Computersystem 500 may be the same or similar to host 110, client 160, ororchestration platform 140 of FIG. 1 , and may include one or moreprocessors and one or more memory devices. In the example shown,computer system 500 may include a trace module 510, a span traversalmodule 515, a span weighting module 520, and a component deploymentmodule 530.

The trace module 510 may enable a processor to receive and performtraces of requests occurring within an application (i.e., traces ofrequests passing through the various components of an application). Thecomponent span traversal module 615 may enable the processor tocalculate or otherwise quantify the number of traces that traverse eachspan between the components of an application.

The span weighting module 620 may enable the processor to associate eachspan with a weight (e.g., by assigning a weight reflective of a numberof traces that traversed the span). The weight may be a raw number oftraces that traversed the span or may be a value reflective of aproportion of traces that traversed the span out of the total number oftraces performed in the application. Component deployment module 630 canenable the processor to deploy applications according to scenariosincluding application components that are merged and split based on theweights of the spans between them.

FIG. 6 depicts a block diagram of a computer system operating inaccordance with one or more aspects of the disclosure. In variousillustrative examples, computer system 600 may correspond to computersystem 100 of FIG. 1 . The computer system may be included within a datacenter that supports virtualization and distributed computing.Virtualization within a data center results in a physical system beingvirtualized using virtual machines to consolidate the data centerinfrastructure and increase operational efficiencies. A virtual machine(VM) may be a program-based emulation of computer hardware. For example,the VM may operate based on computer architecture and functions ofcomputer hardware resources associated with hard disks or other suchmemory. The VM may emulate a physical computing environment, butrequests for a hard disk or memory may be managed by a virtualizationlayer of a computing device to translate these requests to theunderlying physical computing hardware resources. This type ofvirtualization results in multiple VMs sharing physical resources.

In certain implementations, computer system 600 may be connected (e.g.,via a network, such as a Local Area Network (LAN), an intranet, anextranet, or the Internet) to other computer systems. Computer system600 may operate in the capacity of a server or a client computer in aclient-server environment, or as a peer computer in a peer-to-peer ordistributed network environment. Computer system 600 may be provided bya personal computer (PC), a tablet PC, a set-top box (STB), a PersonalDigital Assistant (PDA), a cellular telephone, a web appliance, aserver, a network router, switch or bridge, or any device capable ofexecuting a set of instructions (sequential or otherwise) that specifyactions to be taken by that device. Further, the term “computer” shallinclude any collection of computers that individually or jointly executea set (or multiple sets) of instructions to perform any one or more ofthe methods described herein.

In a further aspect, the computer system 600 may include a processingdevice 602, a volatile memory 604 (e.g., random access memory (RAM)), anon-volatile memory 606 (e.g., read-only memory (ROM) orelectrically-erasable programmable ROM (EEPROM)), and a data storagedevice 616, which may communicate with each other via a bus 608.

Processing device 602 may be provided by one or more processors such asa general purpose processor (such as, for example, a complex instructionset computing (CISC) microprocessor, a reduced instruction set computing(RISC) microprocessor, a very long instruction word (VLIW)microprocessor, a microprocessor implementing other types of instructionsets, or a microprocessor implementing a combination of types ofinstruction sets) or a specialized processor (such as, for example, anapplication specific integrated circuit (ASIC), a field programmablegate array (FPGA), a digital signal processor (DSP), or a networkprocessor).

Computer system 600 may further include a network interface device 622.Computer system 600 also may include a video display unit 610 (e.g., anLCD), an alphanumeric input device 612 (e.g., a keyboard), a cursorcontrol device 614 (e.g., a mouse), and a signal generation device 620.Data storage device 616 may include a non-transitory computer-readablestorage medium 624 on which may store instructions 626 encoding any oneor more of the methods or functions described herein (e.g., methods 200,300), including instructions for implementing the microservicedeployment component 142. Instructions 626 may also reside, completelyor partially, within volatile memory 604 and/or within processing device602 during execution thereof by computer system 600, hence, volatilememory 604 and processing device 602 may also constitutemachine-readable storage media.

While computer-readable storage medium 624 is shown in the illustrativeexamples as a single medium, the term “computer-readable storage medium”shall include a single medium or multiple media (e.g., a centralized ordistributed database, and/or associated caches and servers) that storethe one or more sets of executable instructions. The term“computer-readable storage medium” shall also include any tangiblemedium that is capable of storing or encoding a set of instructions forexecution by a computer that cause the computer to perform any one ormore of the methods described herein. The term “computer-readablestorage medium” shall include, but not be limited to, solid-statememories, optical media, and magnetic media.

Other computer system designs and configurations may also be suitable toimplement the system and methods described herein. The followingexamples illustrate various implementations in accordance with one ormore aspects of the present disclosure.

Although the operations of the methods herein are shown and described ina particular order, the order of the operations of each method may bealtered so that certain operations may be performed in an inverse orderor so that certain operations may be performed, at least in part,concurrently with other operations. In certain implementations,instructions or sub-operations of distinct operations may be in anintermittent and/or alternating manner. In certain implementations, notall operations or sub-operations of the methods herein are required tobe performed.

It is to be understood that the above description is intended to beillustrative, and not restrictive. Many other implementations will beapparent to those of skill in the art upon reading and understanding theabove description. The scope of the disclosure should, therefore, bedetermined with reference to the appended claims, along with the fullscope of equivalents to which such claims are entitled.

In the above description, numerous details are set forth. It will beapparent, however, to one skilled in the art, that aspects of thepresent disclosure may be practiced without these specific details. Insome instances, well-known structures and devices are shown in blockdiagram form, rather than in detail, in order to avoid obscuring thepresent disclosure.

Unless specifically stated otherwise, as apparent from the followingdiscussion, it is appreciated that throughout the description,discussions utilizing terms such as “receiving,” “identifying,”“displaying,” “obtaining,” “creating,” “generating,” “mapping,” or thelike, refer to the action and processes of a computer system, or similarelectronic computing device, that manipulates and transforms datarepresented as physical (electronic) quantities within the computersystem's registers and memories into other data similarly represented asphysical quantities within the computer system memories or registers orother such information storage, transmission or display devices.

The present disclosure also relates to an apparatus for performing theoperations herein. This apparatus may be specially constructed for thespecific purposes, or it may comprise a general purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, such as, but not limited to, any type of diskincluding floppy disks, optical disks, CD-ROMs, and magnetic-opticaldisks, read-only memories (ROMs), random access memories (RAMs), EPROMs,EEPROMs, magnetic or optical cards, or any type of media suitable forstoring electronic instructions, each coupled to a computer system bus.

Aspects of the disclosure presented herein are not inherently related toany particular computer or other apparatus. Various general purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the specified method steps. The structure for avariety of these systems will appear as set forth in the descriptionbelow. In addition, aspects of the present disclosure are not describedwith reference to any particular programming language. It will beappreciated that a variety of programming languages may be used toimplement the teachings of the disclosure as described herein.

Aspects of the present disclosure may be provided as a computer programproduct that may include a machine-readable medium having stored thereoninstructions, which may be used to program a computer system (or otherelectronic devices) to perform a process according to the presentdisclosure. A machine-readable medium includes any mechanism for storingor transmitting information in a form readable by a machine (e.g., acomputer). For example, a machine-readable (e.g., computer-readable)medium includes a machine (e.g., a computer) readable storage medium(e.g., read only memory (“ROM”), random access memory (“RAM”), magneticdisk storage media, optical storage media, flash memory devices, etc.).

The words “example” or “exemplary” are used herein to mean serving as anexample, instance, or illustration. Any aspect or design describedherein as “example” or “exemplary” is not to be construed as preferredor advantageous over other aspects or designs. Rather, use of the words“example” or “exemplary” is intended to present concepts in a concretefashion. As used in this application, the term “or” is intended to meanan inclusive “or” rather than an exclusive “or”. That is, unlessspecified otherwise, or clear from context, “X includes A or B” isintended to mean any of the natural inclusive permutations. That is, ifX includes A; X includes B; or X includes both A and B, then “X includesA or B” is satisfied under any of the foregoing instances. In addition,the articles “a” and “an” as used in this application and the appendedclaims should generally be construed to mean “one or more” unlessspecified otherwise or clear from context to be directed to a singularform. Moreover, use of the term “an embodiment” or “one embodiment” or“an implementation” or “one implementation” throughout is not intendedto mean the same embodiment or implementation unless described as such.Furthermore, the terms “first,” “second,” “third,” “fourth,” etc. asused herein are meant as labels to distinguish among different elementsand may not have an ordinal meaning according to their numericaldesignation.

What is claimed is:
 1. A method comprising: receiving, by a processingdevice, a plurality of traces of requests within an application, whereinthe application comprises a plurality of components; determining anumber of times that each span between the components is traversed by atrace of the plurality of traces; associating each span with acorresponding weight reflecting the number of times that the span istraversed; and selecting a deployment scenario based on the respectiveweights of each of the spans.
 2. The method of claim 1, furthercomprising deploying the components of the application according to thedeployment scenario.
 3. The method of claim 2, wherein deploying thecomponents comprises: responsive to determining that the span between apair of components satisfies a threshold criterion, merging the pair ofcomponents.
 4. The method of claim 2, wherein deploying the componentscomprises: responsive to determining that the span between a pair ofmerged components does not satisfy a threshold criterion, splitting themerged components.
 5. The method of claim 2, wherein each component ofthe plurality of components is a microservice of the application.
 6. Themethod of claim 2, wherein deploying the components comprises grouping aset of components such that each component of the set has a span with acorresponding weight exceeding a threshold and deploying the componentsof the set at a same location.
 7. The method of claim 2, whereindeploying the components comprises determining components having spansbelow a threshold value and deploying a first component of thedetermined components at a different location than a second component ofthe determined components.
 8. A system comprising: a memory; and aprocessing device coupled to the memory, the processing deviceconfigured to: receive a plurality of traces of requests within anapplication, wherein the application comprises a plurality ofcomponents; determine a number of times that each span between thecomponents is traversed by a trace of the plurality of traces; associateeach span with a corresponding weight reflecting the number of timesthat the span is traversed; and select a deployment scenario based onthe respective weights of each of the spans.
 9. The system of claim 8,wherein the processing device is further configured to deploy thecomponents of the application according to the deployment scenario. 10.The system of claim 9, wherein deploying the components comprises,responsive to determining that the span between a pair of componentssatisfies a threshold criterion, merging the pair of components.
 11. Thesystem of claim 9, wherein deploying the components comprises,responsive to determining that the span between a pair of mergedcomponents does not satisfy a threshold criterion, splitting the mergedcomponents.
 12. The system of claim 9, wherein each component of theplurality of components is a microservice of the application.
 13. Thesystem of claim 9, wherein deploying the components comprises grouping aset of components such that each component of the set has a span with acorresponding weight exceeding a threshold and deploying the componentsof the set at a same location.
 14. The system of claim 9, whereindeploying the components comprises determining components having spansbelow a threshold value and deploying a first component of thedetermined components at a different location than a second component ofthe determined components.
 15. A non-transitory machine-readable storagemedium including instructions that, when accessed by a processingdevice, cause the processing device to: receive a plurality of traces ofrequests within an application, wherein the application comprises aplurality of components; determine a number of times that each spanbetween the components is traversed by a trace of the plurality oftraces; associate each span with a corresponding weight reflecting thenumber of times that the span is traversed; and select a deploymentscenario based on the respective weights of each of the spans.
 16. Thenon-transitory machine-readable storage medium of claim 15, wherein theinstructions further cause the processing device to deploy thecomponents of the application according to the deployment scenario. 17.The non-transitory machine-readable storage medium of claim 16, whereindeploying the components comprises, responsive to determining that thespan between a pair of components satisfies a threshold criterion,merging the pair of components.
 18. The non-transitory machine-readablestorage medium of claim 16, wherein deploying the components comprisesresponsive to determining that the span between a pair of mergedcomponents does not satisfy a threshold criterion, splitting the mergedcomponents.
 19. The non-transitory machine-readable storage medium ofclaim 16, wherein deploying the components comprises grouping a set ofcomponents such that each component of the set has a span with acorresponding weight exceeding a threshold and deploying the componentsof the set at a same location.
 20. The non-transitory machine-readablestorage medium of claim 16, wherein deploying the components comprisesidentifying components having spans below a threshold value anddeploying a first component of the identified components at a differentlocation than a second component of the identified components.